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Abstract 

In  this  paper  we  describe  the  design  and  implementation  of  a  system 
for  the  management  of  complex  interactive  graphical  dynamical  simulations. 
The  main  objective  of  the  system  is  to  provide  tools  which  enable  a  graphical 
simulation  to  be  built  with  minimum  effort.  These  tools  include  routines 
for  building  interfaces  (panels  consisting  of  buttons,  sliders,  type  in  boxes, 
etc.),  arranging  the  simulation  workspace,  describing  complex  3D  objects  in 
terms  of  predefined  (or  user  defined)  primitives,  and  providing  objects  with 
properties  used  in  conjunction  with  lighting  models. 

The  need  for  such  a  management  system  is  supported  by  the  facts  that 
both  the  development  effort  and  the  extent  of  machine-specific  knowledge 
needed  to  successfully  implement  an  arbitrary  graphical  simulation  is  signifi¬ 
cant.  It  is  the  aim  of  the  Graphical  Simulation  Management  System  (GSMS) 
to  reduce  these  burdens  and  place  the  power  of  3D  simulation  within  easy 
reach. 

We  have  presented  several  examples  of  dynamical  simulations  in  which 
the  power  and  diversity  of  the  management  system  is  demonstrated. 


"This  research  was  supported  in  part  by  the  AFSOR  University  Research  Initiative  Program 
under  grant  AFSOR-90-0105  and  by  the  National  Science  Foundation’s  Engineering  Research 
Centers  Program:  NSFD  CDR  8803012. 
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1  Introduction 


Simulation  has  become  a  staple  of  system  design.  In  the  case  that  the  sys¬ 
tem  under  simulation  is  amenable  to  a  3D  graphical  representation,  the  ability  to 
graphically  represent  the  result  of  a  complex  dynamical  system  simulation  is  an 
appealing  prospect.  Typically,  the  implementation  of  a  graphical  simulation  is  a 
formidable  technical  endeavor  requiring  a  fairly  in  depth  knowledge  of  specific  ma¬ 
chine  hardware/software  as  well  as  a  significant  amount  of  development  time.  It  is 
the  intent  of  the  Graphical  Simulation  Management  System  (GSMS)  to  relax  both 
of  these  requirements.  By  providing  tools  for 

(i)  building  interfaces  (panels  consisting  of  buttons,  sliders,  type  in  boxes,  etc.), 

(ii)  arranging  the  simulation  workspace, 

(iii)  describing  complex  3D  objects  in  terms  of  predefined  (or  user  defined)  pri- 
matives,  and 

(iv)  endowing  objects  with  properties  used  in  conjunction  with  lighting  models, 

GSMS  does  in  fact  prove  to  reduce  significantly  both  the  development  effort  and 
extent  of  machine  specific  knowledge  required  of  the  simulation  builder. 

Although  the  current  implementation  of  the  management  system  is  in  the  first 
stages  of  development,  the  breadth  of  simulation  scenarios  which  it  already  sup¬ 
ports  is  significantly  vast.  Examples  are  presented  in  section  4.  All  examples  and 
the  management  system  itself  are  written  in  the  C  programming  language.  It  is 
assumed  throughout  that  the  reader  is  familiar  with  C;  an  excellent  reference  is  [1]. 


2  Overview  of  the  System 


GSMS  exists  as  a  C  library  archive  containing  routines  which  may  be  called 
from  an  application  program.  It  is  the  function  of  the  application  program  to 
describe  the  3D  object  models  and  to  set  up  the  simulation  workspace.  Exactly 
how  this  is  accomplished  is  the  major  topic  of  this  paper. 

Also  left  to  the  application  is  the  task  of  providing  GSMS  with  updates  of  the 
dynamical  system  being  simulated.  Although  GSMS  does  no  internal  differential 
equation  solving,  it  does  support  interaction  between  the  simulation  supplied  by 
the  application  program  and  the  application  user.  For  example  one  could  set  up  an 
application  such  that  its  user  may  easily  set  or  reset  certain  simulation  parameters 
(via  graphical  control  panels).  After  setting  the  parameters,  the  user  may  then 
continue  to  watch  the  affect  of  those  changes  on  the  evolution  of  the  system. 

Along  with  providing  a  general  description  of  GSMS,  it  is  the  intent  of  this  paper 
to  explain  how  a  simulation  builder  would  create  a  GSMS  application  program. 
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Several  example  application  programs  are  detailed  in  the  Appendix.  A  typical 
application  follows  the  control  flow  depicted  in  Figure  1.  There  are  essentially 
two  processes  which  are  incorporated  into  the  main  loop  of  an  application:  (i) 
numerical  computation  of  the  current  graphical  state,  and  (ii)  the  display  of  its 
graphical  representation. 


Figure  1:  Typical  application  control  flow 


Routines  to  perform  the  first  of  these  tasks,  numerical  calculation,  must  be 
provided  by  the  application.  For  example,  in  the  case  that  the  system  under 
simulation  is  the  control  system 

(x  =  f(xu)  xG]Rn  ueU  (2.1.) 

I  <J  =  </(a0 

where  u  represents  the  control  input,  U  the  set  of  admissible  controls  and  /(•)  and 
gf)  describe  the  system,  it  is  necessary  to  provide  numerical  solutions  to  Equation 

2.1. 


Depending  on  its  complexity,  the  required  numerical  computation  may  or  may 
not  be  clone  at  actual  execution  time.  In  the  case  that  the  computation  is  ex¬ 
tensive  a  better  strategy  might  be  to  compute  solutions  ‘off-line’  and  simply  use 
the  graphical  simulation  system  as  a  display  tool.  Alternatively  one  may  wish  to 
employ  a  distributed  processing  scheme.  This  sort  of  implementation  is  discussed 
extensively  in  [2], 

3  Anatomy  of  GSMS 


GSMS  can  be  described  in  terms  of  several  main  components: 

1.  panel  manager, 

2.  display  manager, 

3.  3D  model  manager,  and 
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4.  lighting,  materials/color  manager. 

Before  a  detailed  account  is  given  we  first  present  a  brief  overview  of  each  compo¬ 
nent’s  function. 

It  is  the  panel  manager  which  is  responsible  for  the  interactiveness  of  the  ap¬ 
plication.  Through  it  the  application  user  communicates  with  the  simulation,  i.e. 
input.  A  panel  is  simply  a  window  containing  a  collection  of  graphical  input  ‘ac¬ 
tuators’.  An  actuator  may  be  a  slider  controling  some  simulation  parameter  or  a 
button  which  initiates  an  action  when  depressed.  There  are  many  different  types 
of  actuators  (see  Section  3.1  below). 

If  the  panel  manager  provides  organization  for  input  then  certainly  the  display 
manager  supplies  organization  for  output.  Its  main  responsibility  is  the  manage¬ 
ment  of  complex  multi-window  simulations.  The  application  program  specifies 
precisely  the  simulation  workspace  via  the  display  manager. 

The  3D  model  manager  is  the  power  plant  of  GSMS.  It  is  the  manager  which 
eases  the  description  and  manipulation  of  complex  dynamical  3D  objects.  Simply 
stated  a  complex  dynamical  object  is  one  which  consists  of  connections  of  multiple 
subobjects.  Included  in  the  model  manager  is  a  list  of  3D  primatives  (spheres, 
cylinders,  etc.)  which  may  serve  as  the  most  basic  subobject  in  a  complex  object 
description. 

An  essential  component  of  realism  is  added  via  the  lighting,  materials/color 
manager.  This  manager  allows  the  application  to  easily  set  up  lighting  models  and 
endow  objects  with  material  properties.  Material  properties  may  be  associated  at 
the  time  of  object  inception  via  the  3D  model  manager. 

Each  manager’s  function  is  described  in  extensive  detail  below.  The  reader  is 
refered  to  the  coded  examples  in  the  Appendix  for  the  bare  technical  details. 


3.1  Panel  Manager 

Developed  at  NASA  Ames  Research  Center  1  the  ‘Panel  Library’  [3]  is  a  set 
of  routines  for  building  interfaces.  Included  in  this  package  are  tools  for  creating 
panels  or  windows  which  consist  of  various  controls  such  as  buttons,  sliders,  toggles, 
type-in  boxes,  etc.  Such  a  package  is  an  invaluable  asset  for  building  graphical  user 
interfaces. 

Although  the  ‘Panel  Library’  provides  extensive  interface  capabilities  and  flex¬ 
ibility,  its  incorporation  into  an  application  can  be  tedious  and  time  consuming. 
Hence,  the  need  for  a  ‘panel  manager’  emerges.  With  the  aid  of  the  panel  manager 
the  task  of  creating  interfaces  with  the  application  user  is  greatly  simplified. 

xIn  collaboration  with  Sterling  Software;  the  ‘Panel  Library’  is  distributed  freely. 
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Below  the  various  building  blocks  or  actuators  of  an  interface  are  described  in 
detail.  Currently,  the  panel  manager  only  supports  a  subset  of  the  actuators  offered 
by  the  ‘Panel  Library’:  (i)  buttons,  (ii)  sliders,  (iii)  type-ins,  as  well  as  a  new  type 
of  actuator  not  present  in  the  ‘Panel  Library’,  (iv)  variable  (type-ins). 

3.1.1  Creating  a  Panel 
new_panel(char  *str); 

Creation  of  a  panel  is  invoked  by  this  routine  which  initializes  a  panel  with  the 
name  indicated  by  the  str  argument.  All  further  calls  to  other  actuator  placement 
routines  will  place  the  corresponding  actuator  in  this  new  panel.  Without  further 
calls  to  other  building  block  routines  the  panel  will  remain  empty. 

In  the  case  that  is  desirable  to  have  multiple  panels,  new_panel()  must  be 
called  before  each  new  panel  description.  For  example  to  create  an  interface  with 
two  panels  the  structure  of  the  code  would  look  like  the  skeleton  shown  in  Table  1. 

new_panel( "panel  1");  /*  start  describing  first  panel  */ 
calls  to  building  routines 

new_panel( "panel  2");  /*  start  describing  second  panel  */ 
calls  to  building  routines 


Table  1:  Panel  creation  structure 


3.1.2  Actuator  Placement 

Actuators  are  arranged  in  columns  automatically  by  GSMS.  The  action  of 
GSMS  is  to  stack  actuators  in  columns  as  they  are  created.  That  is  the  first 
actuator  created  in  a  panel  is  placed  in  its  lower  left  hand  corner;  while  all  other 
actuators  are  placed  on  top  of  the  previous  one  until  the  routine  new_column() 
is  called. 

new_column() 

When  building  a  panel,  new_column()  tells  GSMS  to  start  placing  actuators 
in  a  new  column.  This  new  column  appears  to  the  right  of  all  previous  columns. 


3.1.3  Buttons 


Button  actuators  perform  specified  actions  when  they  are  selected  or  ‘pressed’ 
with  the  mouse.  There  are  two  types  of  buttons:  (i)  toggle  buttons  and  (ii)  action 
buttons.  Toggle  buttons  have  associated  with  them  a  variable,  while  action  buttons 
(simply  refered  to  as  buttons)  have  associated  with  them  a  procedure  or  function. 

make„toggle_button(char  *str,  float  *ptr) 

The  str  argument  is  a  pointer  to  a  string  which  will  appear  below  the  button  as 
a  label.  When  a  toggle  button  is  selected  its  associated  variable,  *ptr ,  is  logically 
toggled.  That  is  if  *ptr  is  set  to  logical  FALSE  (TRUE  respectively)  depressing  its 
button  actuator  will  toggle  its  value  to  logical  TRUE  (FALSE  respectively). 

For  example,  a  toggle  button  might  be  used  to  control  whether  an  axis  is  dis¬ 
played  or  not  in  a  three  dimensional  scene. 

make.Tmtton(char  *str,  void  (*function)) 

The  str  argument  is  a  pointer  to  a  string  which  will  appear  below  the  button 
as  a  label.  When  an  action  button  is  selected  its  associated  routine,  function (),  is 
invoked. 

For  example,  an  action  button  may  used  to  initiate  a  control  algorithm. 

3.1.4  Sliders 

A  slider  is  used  to  control  the  value  of  a  variable  by  associating  its  numerical 
value  with  a  position  on  a  line  segment.  Once  end  points  of  the  line  segment  are 
specified  the  value  of  the  variable  is  assigned  according  to  the  sliders  position  with 
linear  interpolation  between  the  end  points. 

make_slider(char  *str,  float  min,  float  max,  float  *var,  void  (^function)) 


The  str  argument  is  a  pointer  to  a  string  which  will  appear  below  the  slider 
as  a  label.  Arguments  min  and  max  provide  the  range  of  the  slider  and  var  is  a 
pointer  to  the  variable  to  be  affected.  In  many  cases  it  may  be  desirable  to  have  a 
procedure  or  function  associated  with  a  slider  which  is  invoked  whenever  the  value 
of  its  variable  is  changed.  The  argument  function  specifies  a  pointer  to  such  a 
procedure.  If  it  is  not  desired  to  associate  a  function  to  the  slider,  the  predefined 
special  argument  nulLfunction  should  be  passed. 

For  example,  a  slider  might  be  used  to  control  the  value  of  a  certain  parameter, 
say  9,  of  a  function,  fg(-)  that  is  being  plotted.  Each  time  the  value  of  9  is  changed 
it  is  necessary  to  redraw  the  plot.  Associating  a  routine  that  causes  the  plot  to  be 
redrawn  with  the  slider  controlling  9  accomplishes  this. 


6 


3.1.5  Type-ins 

In  order  to  facilitate  textual  input  from  the  application  user,  type-ins  produce 
a  box  which  when  selected  allow  keyboard  input. 

make_type_in(char  *str,  char  *c_ptr,  void  (^function)) 

The  .str  argument  is  a  pointer  to  a  string  which  will  appear  below  the  type-in 
as  a  label;  while  cjptr  is  a  pointer  to  the  character  string  in  which  the  application 
user’s  input  is  to  be  stored;  and  function  is  a  pointer  to  a  routine  which  is  invoked 
when  the  application  user  hits  the  return  key. 

As  an  example  a  type-in  box  would  be  useful  to  specify  the  name  of  a  file  which 
is  to  be  read. 

3.1.6  Variables 

Variables  are  type-in  like  boxes  whose  input  is  expected  to  be  a  floating  point 
value.  Associated  with  a  variable  box  is  in  a  floating  point  variable.  Upon  selection 
its  value  is  set  to  that  specified  by  the  application  user.  Additionally  a  procedure 
may  be  associated  with  the  variable  box. 

make_variable(char  *str,  float  *ptr,  void  (*function)) 

The  str  argument  is  a  pointer  to  a  string  which  will  appear  below  the  variable 
box  as  a  label;  while  ptr  is  a  pointer  to  the  floating  point  variable  which  is  affected 
by  the  application  user’s  input;  and  function  is  a  pointer  to  a  routine  which  is 
invoked  when  the  application  user  hits  the  return  key. 

3.1.T  Reports 

Reports  provide  a  way  for  the  application  to  communicate  with  its  user.  When 
called  with  an  associated  message,  a  window  is  created  and  displayed  with  that 
message  as  its  content  along  with  a  button  labeled  ‘OK’.  The  action  of  the  ‘OK’ 
button  is  to  destroy  its  parent  window. 

report_window(char  *str) 

The  *str  argument  is  a  pointer  to  a  string  which  will  appear  as  the  message  of 
the  newly  created  report  window. 

3.2  Display  Manager 

For  a  graphical  simulation  using  multiple  windows,  keeping  track  of  the  data 
flow  to  each  window  can  become  quite  cumbersome  without  the  aid  of  a  high  level 
manager.  Consider  a  typical  case  where  it  is  desired  to  construct  a  graphical  sim¬ 
ulation  which  consists  of  several  windows.  Say  for  instance  one  is  interested  in 
building  a  simulation  with  (i)  a  3D  graphical  representation  of  the  ‘real’  system, 
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(ii)  one  or  more  2D  (or  perhaps  3D)  plot(s)  of  some  pertinent  data,  (iii)  a  window 
in  which  the  user  can  construct  an  input  function  with  the  mouse  interactively, 
and  (iv)  various  panels  constructed  using  the  panel  manager  of  the  previous  sec¬ 
tion.  Clearly  one  can  see  that  the  situation  can  become  quite  tedious  without  the 
incorporation  of  some  structure,  i.e.  a  manager.  This  is  the  charge  of  the  display 
manager. 

The  display  manager  consists  of  a  list  of  routines  which  oversee  the  creation 
and  display  of  multiple  window  applications.  Since  the  objects  contained  in  the 
windows  are  of  a  dynamic  nature  it  is  necessary  that  the  application  program  ask 
the  display  manager  to  update  its  windows  often  enough,  e.g.  once  every  iteration 
through  the  main  control  loop  (Figure  1).  The  display  manager  routine  which 
performs  this  update  is  called  do_window_stuff(). 

A  pictorial  representation  of  this  routine’s  action  is  displayed  in  Figure  2.  When 
called  do_window_stuff()  cycles  once  through  every  Graphic  in  the  application 
performing  the  required  action  for  that  Graphic’s  type.  In  addition  it  automatically 
takes  care  of  updating  the  panels. 


Figure  2:  Display  manger  action  (a  call  to  do_window_stuff()  ) 


3.2.1  The  ‘Graphic’  Structure 

In  providing  structure  to  the  problem  of  multiple  window  display  it  is  necessary 
to  introduce  a  generalized  notion  (or  more  precisely  a  data  structure)  capable  of 
representing  window  types  of  interest.  As  a  matter  of  nomenclature  this  concept 
of  a  generalized  window  is  called  a  Graphic.  Major  elements  of  the  Graphic  data 
structure  are  shown  in  a  partial  listing  of  its  declaration  given  in  Table  2. 


Each  of  these  fields  of  the  data  structure  will  be  explained  in  the  following. 
Depending  on  the  type  of  Graphic  some  fields  of  its  data  structure  will  be  applicable 
and  some  will  not. 
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typedef  struct  graphic  { 

int  type,  color,  new_data; 
char  title [STRLEN] ; 


Graph  graph; 

Rect  *R; 

int  interpolation; 


int  (*render)(); 

}  Graphic; 

Table  2:  Graphic  data  structure 


title  This  field  of  the  structure  holds  the  name  or  title  of  the  window.  Each  display 
window’s  title  appears  in  the  upper  left  hand  corner  during  application  execution. 

type  As  has  already  been  discussed,  it  is  desired  that  the  simulation  application 
display  several  different  types  of  windows.  It  is  the  type  field  of  the  data  structure 
which  is  assigned  to  contain  window  type  information.  Table  3  lists  the  basic  types 
of  Graphics  available.  The  most  basic  delineation  within  Graphic  types  is  that 
between  2D  and  3D.  Contents  of  all  2D  Graphic  types  are  assumed  to  be  data 
plots. 


display  type 

description 

G_3D 

CONSTRUCTOR 

ARRAY 

ARRAY  _vs.ARR.AY 
LINK-LIST 
INCREMENTAL 

3  dimensional  perspective  projection 
application  user  buildable  x-y  plots 
array  versus  index  plots 
(y)  array  versus  (x)  array  plots 
(x,y)  pairs  stored  in  link-list 
update  plot  only  (no  erase) 

Table  3:  Graphic  types 


new-data,  color,  and  interpolation  In  the  case  of  a  G_3D  Graphic  the  new_data, 
color  and  interpolation  fields  are  ignored.  In  all  other  cases  the  content  of  the 
Graphic  is  assumed  to  be  a  2D  plot.  In  this  case  the  new„.data  field  is  a  boolean 
which  determines  whether  the  contents  of  the  Graphic  have  changed.  This  field 
is  typically  set  by  the  application  as  a  cue  to  the  display  manager  that  a  cer¬ 
tain  2D  plot  must  be  redrawn.  Interpolation  type  between  adjacent  points  in 
the  plot  is  specified  via  the  interpolation  field  as  one  of  either  DISCRETE  or 
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LINE_SEGMENT.  Graph  color  is  specified  by  the  color  field  and  is  an  integer 
index  into  a  color  table  (each  entry  ol  the  table  consists  of  three  short  integers 
signifying  the  level  of  red,  green,  and  blue  components  of  the  color).  See  section 
3.2.2  for  more  about  colors. 

render  The  render  field  of  the  Graphic  data  structure  is  a  pointer  to  routine  which 
contains  the  drawing  commands  for  its  parent  Graphic.  In  the  case  of  a  G_3D  or 
INCREMENTAL  Graphic  this  routine  must  be  provided  by  the  application  for 
proper  execution.  In  all  other  cases  render  is  set  internally. 

R  For  the  case  of  2D  plots,  R  describes  the  rectangle  of  bounds  for  the  graph.  It  is 
of  type  Red  which  has  four  floating  point  numbers  as  its  elements  (xm,  xM,  ym ,  yM), 
where  ( xm,ym )  is  the  lower  left  hand  corner  of  the  rectangle  and  ( xM,yM )  is  the 
upper  right  corner. 

graph  Again,  graph  is  used  only  in  the  case  that  the  Graphic  contains  a  2D  plot. 
It  is  a  data  structure  itself  of  type  Graph  and  represents  the  2D  data  of  the  Graphic 
in  one  of  three  ways:  (i)  in  a  link  list  of  floating  point  pairs,  (see  the  Appendix  for 
an  explanation  of  the  link  list  utility),  or  (ii)  as  an  array  of  floating  point  numbers 
versus  its  index,  (iii)  as  an  array  of  floating  point  numbers  versus  another  array 
of  floating  point  numbers.  These  three  representations  correspond  directly  to  the 
Graphic  types  LINK-LIST,  ARRAY,  and  ARRAY _vs_ARRAY  given  in  Table  3. 
The  structure  definition  is  presented  in  Table  4.  In  the  case  that  the  Graphic 
type  indicates  an  array  type  (i.e.  ARRAY  or  ARRAY _vs_ARRAY),  the  data  is 
represented  in  terms  of  the  structure  elements  n-pts,  x  and  y.  In  this  case  n_pts 
represents  the  number  of  points  in  the  graph,  x  a  pointer  to  the  graph’s  abscissa 
data  (if  used)  and  y,  a  pointer  to  the  graph’s  ordinate  data. 


typedef  struct  graph  { 
Link_list  *list; 
float  *x,  *y; 
int  n_pts; 

}  Graph; 

Table  4:  Graph  data  structure 


3.2.2  Color 

Colors  may  be  specified  by  three  quantities  indicating  the  level  of  red,  green, 
and  blue  components.  The  following  routines  provide  tools  for  the  definition  and 
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use  of  colors.  Table  5  indicates  a  code  fragment  which  illustrates  the  use  of  each 
routine. 

color_entry(int  index,  int  r,  int  g,  int  b) 

Associates  the  positive  integer  index  with  the  color  specified  by  r,  g,  and  b. 
This  index  is  used  by  the  routine  set_color()  and  must  be  less  than  256. 

set_color(int  index) 

Sets  the  current  drawing  color  to  that  of  the  entry  at  index.  It  is  assumed  that 
the  entry  has  been  set  with  the  color_entry()  routine. 

map _interpolated_colors(float  min,  float  max) 

It  is  sometimes  convenient  to  associate  the  magnitude  of  a  quantity  with  a 
color.  In  the  case  that  the  quantity  of  interest  represents  temperature,  associating 
dark  blue  with  low  temperatures  and  red  with  high  temperatures  is  a  natural 
scheme.  Using  this  analogy  a  color  mapping  may  be  performed  which  associates 
the  value  min  with  BLUE  and  the  value  max  with  RED  by  invoking  the  routine 
map  _interpolated_colors.  Values  between  the  two  endpoints  are  interpolated 
smoothly. 

interpolate_color_and_set(float  val,  float  min,  float  max) 

After  color  entries  have  been  set  by  the  routine  map  Jnterpolated_colors  this 
routine  may  be  used  to  set  the  drawing  color  to  the  color  associated  with  val.  It  is 
assumed  that  val  is  between  min  and  max. 


3.2.3  Specification  of  Workspace 

A  typical  application  using  the  display  manager  would  set  up  its  workspace 
up  with  the  structure  of  the  skeleton  shown  in  Table  6.  The  reader  is  refered  to 
applications  in  Section  4  for  explicit  examples. 

init_graph(Graphic  *G,  render) 

A  pointer  to  a  Graphic,  the  G  argument  is  assumed  to  have  elements  initialized 
to  proper  values  before  the  call.  The  render  argument  is  optional.  It  is  the  address 
of  a  function  which  will  be  called  when  its  associated  graph  must  be  drawn. 
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#define  REDISH  28  /*  some  integer  between  0  and  255  */ 

{  float  temperature; 

color_entry(REDISH,  240,  35,  55); 

set_color (REDISH) 

/*  do  some  drawing  with  REDISH  color  */ 

map_interpolated_colors(0 . 0 ,  100 .0) ; 

;  /*  some  temperature  calculation  */ 

interpolate_color_and_jset (temperature ,  0.0,  100.0); 


} 


Table  5:  Colors:  An  Example 


Graphic  G1  ,G2 .  Gn; 

set  appropriate  fields  of  G1 
init_graph(Gl ,  my  .render)  ; 

set  appropriate  fields  of  Gn 
init_graph(Gn) ; 

Table  6:  Window  creation  template 


3.3  3D  Model  Manager 

At  the  heart  of  GSMS,  the  model  manager  provides  tools  by  which  to  describe 
complex  dynamical  3D  objects.  Here  a  dynamical  object  is  one  whose  3D  descrip¬ 
tion  (or  state)  changes  over  time.  Unlike  the  case  of  modeling  static  3D  objects  it 
is  necessary  to  describe  how  a  dynamical  object  changes.  For  instance  a  multi-link 
robot  arm  moving  through  space  towards  a  target  item  is  a  dynamical  object  whose 
orientation  and  position  of  links  determines  its  configuration  at  each  time  instant. 

3.3.1  Describing  a  Dynamical  Object 

How  to  describe  a  dynamical  object?  This  is  the  fundamental  question  which 
the  model  manager  addresses.  A  complex  object  may  be  described  in  terms  of  its 
parts  (or  subobjects)  and  how  they  are  connected.  Consider  the  example  of  the 
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robot  arm  with  two  identical  rigid  links  of  given  dimensions.  Presumably  the  first 
link  of  the  arm  is  fastened  to  a  base  or  ground.  This  link  is  free  to  pivot  around 
an  axis  perpendicular  to  the  ground.  Next  the  second  link  is  attached  to  the  first 
through  a  pivot  connection  allowing  rotation  only  within  a  plane.  Hence  the  arm 
has  been  completely  described  in  terms  of  other  composite  static  objects  and  their 
connections.  These  types  of  connections  may  be  described  by  affine  transformations 
(scalings,  rotations,  and  translations)  in  three  dimensional  space.  It  is  in  this  vain 
in  which  the  manager  models  3D  objects.  A  detailed  account  follows. 

3.3.2  The  Object  Network 

To  illustrate  the  idea  of  describing  three  dimensional  objects  in  terms  of  affine 
combinations  of  subobjects,  consider  the  case  of  developing  an  object  model  of  a 
human  being.  One  simple  representation  of  a  human  is  shown  in  Figure  3. 


Figure  3:  Stick  model  of  a  human  being 


The  stick  model  in  Figure  3  might  be  thought  of  as  an  object  network.  As  in 
any  network,  the  stick  model  network  consists  of  nodes  and  branches.  In  the  case 
of  an  object  network  nodes  represent  represent  subobjects  and/or  primatives  while 
branches  represent  connections  between  objects.  All  nodes  in  an  object  graph  have 
a  common  ancestor  or  root  which  will  be  refered  to  as  ‘ground’.  It  is  the  ground 
frame  of  reference  in  which  GSMS  renders  all  scenes.  In  Figure  3  one  may  think  of 
the  torso  as  being  grounded. 

3.3.3  Acyclical  Object  Networks 

A  limitation  to  the  current  implementation  of  the  object  manager  is  that  it  is 
only  able  to  manipulate  objects  whose  networks  are  acyclical.  An  acyclical  object 
network  is  one  whose  graph  has  no  closed  loops.  Objects  with  cyclical  graphs 
require  much  higher  level  processing  for  the  computation  of  thier  graphical  state 
than  is  currently  supported.  This  area  is  a  key  focus  of  future  expansion  for  GSMS. 

Unless  otherwise  noted  all  network  graphs  encountered  in  the  sequel  will  be 
assumed  to  be  acyclical. 
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3.3.4  Connections 


As  mentioned  earlier,  connections  between  objects  are  described  as  affine  trans¬ 
formations  (scalings,  rotations  and  translations)  in  three  dimensional  space.  A  de¬ 
tailed  discussion  of  affine  transformations  and  tlieir  implementation  may  be  found 
in  [4].  Consider  the  simple  case  of  describing  a  ball  and  socket  type  connection 
between  two  objects,  parent  and  child.  The  parent  object  is  defined  as  the  one 
which  is  closest  to  ground.  These  rotations  and  translations  are  performed  relative 
to  the  parent  object.  A  ball  and  socket  connection  implies  full  rotational  freedom; 
therefore,  this  type  of  connection  may  be  fully  described  as  a  rotation  in  three 
dimensional  space.  Realistically,  though,  the  rotational  freedom  of  the  connection 
must  be  constrained  in  some  way,  e.g.  to  avoid  collisions  between  parent  and  child 
objects.  Constraining  connections  is  left  as  the  responsibility  of  the  application. 

Figure  4  is  an  example  of  a  more  informative  representation  of  an  object  net¬ 
work.  Here  branches  are  replaced  with  labeled  boxes  associating  a  name  with  each 
branch  (or  subobject). 


Figure  4:  Object  model  of  a  human  being 


3.3.5  Object  Primitives 

The  description  of  a  3D  object  proposed  above  implies  a  hierarchy;  and  there¬ 
fore,  the  existence  of  a  set  of  primative  objects  with  which  all  other  objects  (or  at 
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least  objects  ol  interest)  may  be  constructed.  One  can  always  find  such  a  primative 
set  (take  the  set  of  all  3D  objects);  however,  it  is  the  set  of  primatives  with  the 
fewest  elements  which  will  be  made  the  most  useful.  A  more  precise  way  to  state 
this  is  the  following:  it  is  desired  to  find  the  smallest  set  of  3D  graphical  primi¬ 
tives  whose  span  under  affine  spatial  transformations  covers  the  set  of  all  complex 
objects  of  interest. 

Among  the  3D  primative  solids  currently  supported  by  GSMS  are 

1.  cubes, 

2.  cylinders,  and 

3.  spheres. 

Since  GSMS  allows  for  affine  transformation  on  any  object  in  this  primative  set  an 
entire  class  of  objects  may  be  generated,  e.g.  ellipsoids  from  spheres. 


3.3.6  The  Object_3D  data  structure 

In  order  to  implement  the  notion  of  an  object  network  it  is  necessary  to  deter¬ 
mine  a  representation  for  one  of  its  elements,  i.e.  an  object.  This  representation  or 
data  structure  is  given  the  name  Object_3D.  Displayed  in  Table  7  are  the  major 
fields  of  the  data  structure  Object_3D.  Because  the  fields  of  this  structure  are 
typically  set  via  display  manager  routines  for  placing  objects  into  a  network,  the 
application  need  not  directly  manipulate  these  fields.  The  reader  is  refered  to  the 
examples  in  Section  4. 


typedef  struct  objected  { 

struct  object_3d  *parent; 
struct  object_3d  *sub; 
struct  objected  *next; 

Transform  *xform; 

int  type; 

char  *data;  /*  pointer  to  objected  specific  structure  */ 


}  0bject_3d; 

Table  7:  The  Object_3D  data  structure 
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parent,  sub  and  next  An  acyclic.al  network  may  be  thought  of  as  a  tree  like 
structure  which  starts  at  ground  with  a  single  root  node.  As  a  member  of  an 
acyclical  object  network,  a  node  may  have  associated  with  it  one  or  all  of  either 
(i)  a  parent  node,  (ii)  a  sub-node,  or  (iii)  a  next-node.  For  any  arbitrary  node 
in  the  network  there  is  a  unique  parent  node  from  which  it  is  spawned;  it  may, 
however,  have  multiple  siblings  (nexts)  as  well  as  multiple  children  (subs).  Note 
that  because  it  belongs  to  an  acyclical  network,  an  object  is  connected  to  only  its 
parent  and  its  children  (subs). 

xform  This  field  of  the  structure  holds  information  regarding  the  connection 
(affine  transformation)  between  this  object  and  its  parent  object.  Note  that  the 
field  xform  is  itself  a  structure.  The  structure  Transform  is  shown  in  table  8  and 
contains  the  nine  quantities  needed  to  uniquely  determine  an  affine  transforma¬ 
tion.  Scale,  position,  and  rotation  information  are  stored  as  vectors  in  1R3  and  may 
be  accessed  via  the  predefined  constants  X,Y  and  Z.  For  example  to  access  the 
the  ^-coordinate  of  the  position  information  of  an  associated  object  called  Ob  the 
correct  reference  would  be  Ob->xform->position[Yj. 


typedef  struct  transform  { 
float  scale  [3] ; 
float  position [3] ; 
float  rotation[3]; 

}  Transform; 

Table  8:  The  Transform  data  structure 


type  and  data  This  field  holds  an  integer  value  which  indicates  the  type  of  object 
which  the  structure  describes.  A  list  of  object  types  employed  by  GSMS  is  given 
in  Table  9.  The  field  data  is  a  pointer  to  a  structure  containing  the  necessary  data 
for  the  type. 


object  type 

Structure  Name 

description 

USER 

CYLINDER 

SPHERE 

DEPTH-POLYGON 

POLYGON-LIST 

Cylinder 

Sphere 

Depth-polygon 
Polygon  Jist 

application  definable 
polygonal  cylinder 
polygonal  sphere 

stretched  polygon  (along  polygon  normal) 
arbitrary  polygonal  object 

Table  9;  Object  types 
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3.3.7  Instantiating  an  object 

When  describing  a  complex  three  dimensional  object  via  the  GSMS  model  man¬ 
ager,  an  application  must  first  call  the  model  manager  routine  new_object().  Be¬ 
sides  providing  the  necessary  initialization  of  the  network  graph  it  returns  a  pointer 
to  the  root  object.  Access  to  this  pointer  is  essential  in  defining  render  routines 
(see  the  appendix  for  examples). 

new_object() 

Initializes  and  returns  a  pointer  to  the  ‘root’  node  of  the  object  graph.  Typically 
this  routine  is  invoked  only  once  at  the  begining  of  the  object  graph  definition. 

draw_object(Object_3d  ^object) 

Draws  the  object  tree  ol  the  complex  object  starting  at  the  cell  specified  as  its 
argument  object.  To  render  the  entire  complex  object  the  application  would  pass 
the  ‘root’  node  address  as  the  argument.  The  operation  of  this  routine  is  detailed 
precisely  in  Section  3.3.9. 

For  each  of  the  object  types  listed  in  Table  9  there  is  an  associated  routine 
which  takes  pertinent  object  geometry  and  materials  information  and  places  it  into 
the  appropriate  data  structure.  In  all  cases  these  routines  take  as  an  argument  a 
pointer  to  the  appropriate  data  structure.  It  is  the  responsibility  of  the  application 
to  allocate  the  necessary  memory  to  hold  the  structure.  The  operation  and  syntax 
of  these  routines  is  detailed  in  the  following. 

make_cylinder(Cylinder  *c,  float  radius,  height,  int  n_sides,  top_material, 
bottorn_material,  edge_material_l,  edge_material_2,  char  a) 

Instantiates  a  polygonal  approximation  to  a  cylindrical  shell  with  origin  coinci¬ 
dent  with  its  centroid  (assuming  uniform  mass)  in  the  orientation  aligned  with  the 
axis  indicated  in  the  argument  a  G  (a1,  y,  2) .  The  resolution  of  the  polygon  approxi¬ 
mation  is  controlled  by  the  argument  nsides  and  signifies  the  number  of  rectangles 
which  will  comprise  the  walls  of  the  cylinder.  Arguments  edge-material-1  and 
edge-materiaL2  indicate  materials  of  alternating  polygonal  sections  of  the  cylinder 
walls.  All  remaining  arguments  are  self  explanatory. 

make_sphere(Sphere  *s,  float  radius,  int  n_sides,  material!.,  material2) 

Instantiates  a  polygonal  approximation  to  a  spherical  shell  with  origin  at  its  cen¬ 
ter.  Arguments  materiall  and  materials  indicate  materials  of  alternating  polygonal 
sections  of  the  sphere.  The  resolution  of  the  polygon  approximation  is  controlled 
by  the  argument  nsides  and  signifies  the  number  of  polygons  lying  on  the  equator 
of  the  sphere.  Note  if  it  is  desired  to  have  a  sphere  of  uniform  material  one  may 
simply  indicate  the  same  material  for  both  materiall  and  materials.  All  remaining 
arguments  are  self  explanatory. 
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3.3.8  Some  Modeling  Routines 


move._object_origin(Object_3D  *Ob,  float  dx,  dy,  dz) 

Incrementally  adjusts  the  origin  of  the  object  Ob  by  the  specified  coordinates 
dx,  dy,  dz.  Since  it  is  the  origin  to  which  connections  are  assumed  to  be  made, 
this  routine  provides  control  over  the  location  of  connections  between  objects.  For 
instance,  in  the  case  of  a  two  armed  rigid  robotic  linkage  modeled  as  two  cylinders, 
object  origins  should  occur  at  the  base  of  the  cylinders  and  not  the  default  centroid 
location. 

3.3.9  Rendering  an  Object  (  *  application  transparent) 

Having  introduced  the  concept  of  an  object  network,  and  consequently  the 
Object_3D  structure,  the  drawing  ot  an  object  is  easily  accomplished.  Specifically, 
one  may  apply  a  recursive  algorithm  to  render  any  object  described  by  an  acyclical 
object  network.  Table  10  displays  the  C  code  instructions  which  GSMS  uses  for  an 
object’s  rendering. 


draw_object(0) 

Objected  *0; 

{  ‘ 

Objected  *0b; 

f or (  0b=0 ;  Ob  !=  (Objected  *)  0;  Ob  =  0b->next)  { 
pushmatrixQ  ; 

render(Ob) ; 

if  (0b->sub  !  =  (Objected  *)  0)  draw_obj set (0b->sub) ; 
popmatrixQ  ; 

} 

} 

Table  10:  Drawing  an  object  recursively 


3.3.10  Forming  the  Object  Network 

GSMS  provides  two  basic  tools  for  constructing  an  object  network  spawn_sub() 
and  spawn_next().  Note  that  object  geometry  information  is  referenced  via  a 
character  pointer  data.  Hence  whatever  type  data  is  stored  at  location  data  it 
should  be  type  cast  to  the  type  char  in  a  call  to  one  of  these  routines.  Described 
below  is  their  syntax  and  operation. 

Object_3D  *spawn_sub(int  type,  char  *data,  Object_3D  ^parent,  Trans¬ 
form  *xform) 
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This  routine  enters  an  object  into  the  network  as  a  subobject ,  as  the  child  of  the 
object  parent.  It  returns  a  pointer  to  the  Object_3D  element  in  which  this  object 
is  placed.  Initial  connection  information  is  given  in  the  argument  xform.  It  is  a 
pointer  to  the  transformation  information  which  describes  the  connection  between 
this  new  object  and  its  parent.  As  such  it  is  the  responsibility  of  the  application 
to  allocate  memory  for  the  transformation  information.  This  may  be  accomplished 
via  the  GSMS  routine  new_transform();  see  below.  Other  information  stored  in 
the  object  network  such  as  the  object’s  type  and  a  pointer  to  a  block  of  data  which 
describes  the  object  are  also  required. 

Objec:t_3D  *spawn_next(int  type,  char  Mata,  Object_3D  *from,  Trans¬ 
form  *xform) 

This  routine  enters  an  object  into  the  network  as  a  next-object ,  an  object  on  the 
same  level  of  the  object  from..  It  returns  a  pointer  to  the  Object_3D  element  in 
which  this  object  is  placed.  Initial  connection  information  is  given  in  the  argument 
xform.  It  is  a  pointer  to  the  transformation  information  which  describes  the  con¬ 
nection  between  this  new  object  and  its  parent  (the  same  as  from' s  parent).  As  such 
it  is  the  responsibility  of  the  application  to  allocate  memory  for  the  transformation 
information.  This  may  be  accomplished  the  GSMS  routine  new_transform(),  see 
below.  Other  information  stored  in  the  object  network  such  as  the  object’s  type 
and  a  pointer  to  a  block  of  data  which  describes  the  object  are  also  required. 

Transform  *new_transform(float  sx,  sy,  sz,  px,  py,  pz,  rx,  ry,  rz) 

Returning  a  pointer  to  a  Transform  structure,  this  routine  allocates  and  stores 
the  scale  (sx,sy,sz),  rotation  (rx,ry,rz),  and  position  (px,py,pz)  information  into 
a  block  of  memory.  Angles  are  assumed  to  be  in  degrees.  It  is  most  useful  in 
conjunction  with  the  spawn_next()  and  spawn_sub()  routines. 

3.4  Properties/Lighting  Manager 

The  properties  and  lighting  manager  is  the  least  developed  of  all  the  managers 
here  and  therefore  the  manager  which  could  be  most  improved.  It  is  provided  in 
its  current  rudimentary  form,  however,  to  meet  the  main  objective  of  GSMS:  to 
provide  a  fast  way  to  develop  high  quality  graphical  simulations.  In  this  context 
‘high  quality’  refers  to  simulations  which  incorporate  lighting  and  material  models 
contributing  to  the  resulting  realism  of  the  overall  simulation. 

Currently  in  GSMS  there  is  only  one  lighting  model  which  consists  of  two  infinite 
white  light  sources:  one  hitting  the  x-y  plane  from  above  at  an  angle  of  45°  and 
on  from  below  at  the  same  angle.  Another  more  grave  drawback  of  the  materials 
manager  is  that  there  are  no  management  routines  to  deal  with  the  creation  and 
manipulation  of  user  defined  materials.  2  There  is  however  a  small  set  of  predefined 
materials  listed  in  Table  11  which  may  be  accessed  by  the  application. 

2  Providing  more  flexibility  in  the  description  of  the  lighting  model  as  well  as  providing  routines 
for  the  creation  and  management  of  user  defined  materials  are  key  areas  of  future  work  on  GSMS. 
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Name 

Description 

GREYJV1AT 
GOLDEN  JVI  AT 
RED.MAT 
GREEN-MAT 
BLUE-MAT 

grey  metallic  material 
gold  metallic  material 
red  metallic  material 
green  metallic  material 
blue  metallic  material 

Table  11:  Predefined  Materials 


4  Applications 


This  section  presents  brief  descriptions  of  three  example  GSMS  applications. 
The  appendix  contains  the  example  programs  in  full  coded  detail.  Emphasis  in 
these  examples  is  placed  on  the  graphical  description  and  set-up  of  the  applica¬ 
tion/user  interface  and  ignores  the  details  of  the  method  of  solving  the  dynamical 
system.  All  of  the  applications  presented  here  are  organized  as  two  distinct  files: 

(i)  one  which  describes  the  physical  three  dimensional  model  (usually  model. c)  and 

(ii)  one  which  describes  the  set-up  of  the  workspace.  Note  the  compact  and  suc¬ 
cinct  fashion  in  which  potentially  cumbersome  and  clumsy  graphical  simulations 
can  be  described  with  GSMS. 

In  all  GSMS  applications  which  include  a  3-D  window  a  navigation  panel  is 
automatically  created.  This  navigation  panel  consists  of  three  sliders  which  control 
the  look  at  position  (the  user  is  always  looking  at  the  origin)  via  polar  co-ordinates. 
Consequently  the  default  labels  for  these  sliders  are  ‘distance’,  ‘Pan  X’,  and  ‘Pan 
Y’. 

4.1  Simple  Pendulum 

Probably  the  best  understood  and  most  analyzed  control  system  which  exists 
is  that  of  the  simple  pendulum.  In  this  example  a  pendulum  is  modeled  as  an 
interconnection  of  three  cylinders  in  opposing  orientations.  These  cylinder  objects 
are  contained  in  a  single  branch  of  an  acyclical  object  network. 

4.2  Planet/Moon  System 

Planetary  motion  is  another  area  in  which  relatively  simple  dynamical  models 
may  be  developed.  In  this  example  a  planet  with  two  small  moons  in  its  orbit  is 
modeled  by  three  spheres  in  a  three  dimensional  field  of  ‘stars’.  The  three  sphere 
objects  are  placed  in  a  lateral  object  network,  i.e.  they  are  all  siblings.  The  star 
field  is  implemented  by  providing  an  application  defined  render  function  which  first 
calls  the  GSMS  default  render  and  then  the  star  field  render. 

4.3  Elephant  Trunk  Manipulator 

One  of  the  most  dextrous  naturally  occuring  manipulators  is  that  of  the  ele- 
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pliant’s  trunk.  Using  GSMS  it  is  especially  simple  to  describe  such  a  manipulator 
as  one  branch  of  an  acyclical  object  network.  Having  described  the  elephant  trunk 
so  compactly,  one  may  then  focus  his  attention  on  its  control.  The  application 
presented  here  involves  a  scheme  for  position  control  (code  deleted).  Modeling  the 
elephant  trunk  as  a  series  connection  of  n  rigid  links,  one  sees  that  there  is  a  great 
many  degrees  of  freedom  with  respect  to  position  control.  Having  a  three  dimen¬ 
sional  representation  of  a  control  algorithm’s  behavior  can  be  a  valuable  source  of 
information  to  the  control  engineer. 
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Appendix  (Coded  Examples) 


(Makefile) 


# 

Makefile  for  GSMS  "pendulum"  application  5/30/91  A.T. 

# 


PENDULUM. 0  =  pendulum. o  model. o 
IRIS  =  IRIS.4D 

10 

GSMS_DIR  =  /everest/users/tonyt 

INCLUDE  DIR  =  $(GSMS  DIR)/include 
LIB.DIR  =  $(GSMS_DIR)  /lib 

INCLUDE_DIRS=  -I$(INCLUDE_DIR)  -I/usr/local/include 
LIB_DIRS=  — LS(LIBJDIR)  -L/usr/local/lib 

GSMS_LIB  =  — lgraph  — lpnl_mngr  — llinkjist  — Ipanel 

LIBEs"  =  S(GSMS.LIB)  -Igf-lm  ~  20 

CFLAGS  =  -DS(IRIS)  $(INCLUDE_DIRS)  $(LIB_DIRS) 
pendulum:  S(PENDULUM.O) 

$(CC)  $(CFLAGS)  S(PENDULUM.O)  -o  pendulum  S(LIBES) 
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make_model(model.c) 


^include  <gl.h> 

^include  <math.h> 

^include  "display. h" 

^include  "light. h" 

^include  "3d_tools.h" 

#  define  ARM.RADIUS  0.1 

I*  pendulum  angle  */ 

float  *theta_ptr; 

J*  base  parameters  */ 

float  base_radius=;0.3,  base_width=0.1; 
int  base_sides  =  10; 

I*  ann  parameters  */ 

float  arm_radius='ARM_RADIUS,  arm_width=2.0; 
int  arm_sides  =  30; 

/*  weight  parameters  */ 

float  weight_radius=0.4,  weight_width=ARM_RADIUS; 
Int  weigh  t_sides  ==  20; 

I*  The  objects  */ 

Object_3d  *the_ground,  *base,  *arm,  *weight; 

make_model() 

{ 

int  i; 

Cylinder  base_cyl,  arm_cyl,  weight_cyl; 


10 


20 


30 


make_model 


/*  Describe  the  parts:  double  pendulum  made  completely  from  cylinders  */  40 

/*  base  *1 

make  cylinder(<kbase_cyl,  base_radius,  base_width,  base  sides, 

GREY.MAT,  GREY_MAT,  GREY_MAT,  GREY.MAT,  »y')i 

/  *  arm  */ 

make_cylinder(&;arm_cyl, 

arm  radius, arm  width, armsides,  so 

GREY_MAT,  GREY_MAT,  GREY_MAT,  GREYJVIAT,  >y’); 

/*  weight  */ 
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make_model(model.c) 


make_cylmder(&weight_cyl, 

weight_radius,weight_width,weight_sides, 

GREY_MAT,  GREYMAT,  GREYMAT,  GREY_MAT,  ’z’); 

I*  Describe  the  connections,  i.e.  how  the  parts  go  together  */ 
the_ground  =  new_object(); 

base  =  spawn_next(CYLINDER,  (char  *)  <kbase_cyl,  the_ground, 

new_transform( 

1.0,  1.0,  1.0, 

0.0,  arm_width,  0.0, 

0.0,  0.0,  0.0  ) 

); 

arm  =  spawn_sub(CYLINDER,  (char  *)  &arm_cyl,  base, 

nevv_transform( 

1.0,  1.0,  1.0, 

0.0,  — arm_width/2.0,  0.0, 

0.0,  0.0,  0.0  ) 

); 

weight  =  spawn_sub(CYLINDER,  (char  *)  &weight_cyl,  arm, 

new_transform( 

1.0,  1.0,  1.0, 

0.0,  —  (arm_width/2.0  +  weight jradius),  0.0, 

0.0,  0.0,  0.0  ) 


/*  point  to  active  model  parameters  */ 

theta_ptr  =  &(base—  >xform— >rotation[Z]); 

} 


60 


TO 


80 
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main(pendulum.c) 


^include  <stdio.h> 

^include  <gl.h> 

#include  "math.h" 

^include  "display. h" 

^include  "light;,  h" 

^include  "pnl_manager .h" 

^include  "3d_tools.h" 

^include  "tools.h" 

^include  "graph. h" 

#  define  THETA _PTS  500 

f*  variables  from  model  *j 

extern  Object_3d  *the_ground; 
extern  float  *theta_ptr; 

/*  booleans  */ 

int  automatic  =  0,  fromjile  =  0; 

/  *  misc  *1 

float  frequency  =  0.1,  amplitude^  10,  dummy,  time  =  0,  time_increment=0.1; 
float  theta_data[THETA_PTS]; 
int  theta_index=0; 

/  *  file  stuff  */ 

int  n_data=:0,  index=0; 

char  in_filename[TYPE_IN_LEN]; 

Point2  data[20000]; 

FILE  *fp; 

char  message[80j;  /*  buffer  for  report  window  message  */ 
j  *  procedures  */ 

void  read_data(),  reset_simulation(); 
int  draw_scene(); 

/*  Graphics  */ 

Graphic  Display,  Theta; 

main() 

{ 

window_init(); 

set_up_display(); 

while  (TRUE)  { 

numerical_calculations() ; 


10 


20 


30 


40 


main 


so 
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main-numerical_calculations  (pendulum. c) 


} 


} 


do_window_stuff(); 


set_up_display()  Set_UD  display 

{ 

60 

/*  windows  */ 

prefsize(600,  450); 
sprintf(Display. title,  "Pendulum"); 

Display.type  =  G_3D; 
init_graph.(&;Display,  draw  scene); 

prefsize(600,  250); 
sprintf(Theta. title,  "Theta"); 

Theta,  type  =  ARRAY;  70 

Theta. graiph.y  =  theta_data; 

Theta. grsi.ph.n_pts  =  theta_index; 

Theta. R  =  Box(0.0,  (float")  THETA_PTS,  -180.0,  180.0); 
init_graph(&Theta); 

f*  3D  model  */ 

make_model0; 

/*  panels  (note:  make_model()  to  be  called  first  for  proper  initialization)  */  so 

sprintf(in_filename,  "Ho  File");  /*  initialize  filename  */ 
new_panel("  S  imulat  ion") ; 

make_variable("increment",  &time_increment,  nulljunction); 
make_type_in("f ile  name",  in_filename,  read_data); 
make_toggle_button("  run",  &from_file); 
make_button("  reset",  reset_simulation); 

new_panel("Manual  Control");  90 

make_toggle_button("  automatic",  ^automatic); 

make_slider("frequency",  0.0,  1.0,  ^frequency); 
make_slider("amplitude",  0.0,  270.0,  <kamplitude); 

make_slider("theta",  —180.0,  180.0,  theta_ptr);  /*  from  model  *f 

} 

numerical_calculations()  /*  psuedo  dynamics  */  numerical_CalculatioilS 

{  100 

int  i; 

if  (fromjile)  { 

for  (i=index;  data[i].x<time  Ick.  index<n_data;  i++)  {  } 
index=i; 

*theta_ptr  =  data[index].y; 
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nurnericalcalculations-drawscene(pendulum.c) 


time  +=  timejncrement; 
update_theta_graph(); 

}  else  if  (automatic)  {  no 

*t;heta_ptr  =  amplitude*sin(  (double)  (frequency*time)  ); 
time  +=  timejncrement; 
update_theta_graph(); 

} 

} 

update  theta_graph()  update_theta_graph 

{ 

theta_data[thetajndex]  =  *theta_ptr; 

thetajndex  =  (thetaJndex+l)%THETA_PTS;  120 

Theta. graph. n_pts  =  theta  index; 

Theta. new  data  =  TRUE; 

} 

void  read_data() 

{ 

int  i=0; 

if  (  (fp  =  fopen(in_filename,  "r"))  ==  0)  { 

sprintf(message,  "Unable  to  open  file:  ’’/.s’  ",  in_filename);  130 

report_window(message) ; 

return; 

}; 


wliile(  fscanf(fp,  "*/,f  */.f  '/.f  7,f",  &(data[i].x),  fcdummy,  fedummy,  &(data[i].y))  !=  EOF  )  { 

i++; 

} 

n_data=i; 

printf("Read  '/.d  data  points\n",  n_data);  140 

time  =  data[0].x; 
index=0; 

} 

void  reset  simulation() 

{ 

time  =  data[0].x; 

*theta_ptr  =  data[0].y; 

index=0;  iso 

} 

draw  scene()  draw  scene 

{ 

draw_axis(); 

draw  object(the_ground); 

} 
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(Makefile) 


# 

#  Makefile  for  GSMS  "planet"  application  5/30/91  A.T. 

# 


PLANET. O  =  planet. o  model. o 

IRIS  =  IRIS.4D 

GSMS_DIR  =  /everest/users/tonyt 

INCLUDE  DIR  =  $(GSMS  DIR) /include 
LIB_DIR  =  $(GSMS_DIR)  /lib 

INCLUDE_DIRS=  -I$(INCLUDE_DIR)  -I/usr/local/include 
LIB_DIRS=  — LS(LIBJDIR)  -L/usr/local/Iib 

GSMS_LIB  =  — Igraph  —  lpnljmngr  —  llinklist  — Ipanel 
LIBES  =  $(GSMS_LIB)  -lgl  -lm 

CFLAGS  =  -DS(IRIS)  S(INCLUDE_DIRS)  $(LIB_DIRS) 

planet:  S(PLANET.O) 

$(CC)  $(CFLAGS)  S(PLANET.O)  -o  planet  S(LIBES) 
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up  dat  e  mo  del  (model. c) 


^include  <gl.h> 

^include  <math.h> 

^include  "display. h" 

^include  "light. h" 

#include  "3d_tools  .h" 

#defme  MAX_MOONS  10  /*  maximum  number  of  moons  */ 

/*  global  parameters  */  10 

float  sphere_radius=1.0,  sphere_sides=20,  orbit_var=6.0,  orbit[MAX_MOONS],  n_moons=2; 

/  *  data  structures  assigned  to  hold  object  information  */ 

Sphere  moon_sphere[MAX_MOONS],  planet_sphere; 

/  *  pointers  to  members  of  the  object  graph  *f 

Object_3d  *the_ground;  /*  pointer  to  the  ground  (root)  node  */  20 

Object_3d  *planet,  *moon[MAX_MOONS]; 


make  model() 

{ 

int  i; 

/  *  initialize  object  graph  */ 

the_ground  =  new_object(); 

/*  set  up  specific  object  information  */ 
update__model(); 

I*  place  main  planet  into  object  graph  */ 

planet  =  spawn_next(SPHERE,  (char  *)  &planet_sphere,  the_ground, 

new_transform( 

1.0,  1.0,  1.0, 

0.0,  0.0,  0.0, 

0.0,  15.0,  0.0  ) 

); 

/  *  place  moons  into  object  graph  */ 

for  (i=0;  i<n  moons;  i++)  spawn  moon(i); 

} 

updatemodelQ 

{ 

int  i; 


makejmodel 


30 


40 


update_model 

51 
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update_model-spawn_mo  on  (model. c) 


} 


for  (i=0;  i<n_moons;  i++)  { 

make_sphere(&moon_sphere[i], 

0.4*(rand()%  1000)/ 1000.  *sphere_radius, 

(int)  sphere  sides,  RED_MAT,  RED  MAT); 

} 

make_sphere(&planet_sphere,  sphere_radius, 

(int)  sphere_sides,  BLUE_MAT,  BLUE_MAT); 


spawn_moon(i) 
int  i; 

{ 

orbit  [i]  =  orbit_var*(rand()%1000)/1000.+sphere_radius; 
moonfi]  =  spawn_next(SPHERE,  (char  *)  &moon_sphere[i],  the_ground, 
new_transform( 

1.0,  1.0,  1.0, 

orbit[i],  0.0,  0.0, 

0.0,  0.0,  0.0  ) 

); 

} 


60 

spawnmoon 
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main(planet.c) 


^include  <stdio.h> 

#include  <gl.h> 

^include  "math.h" 

^include  "display. h" 

#include  "light. h" 

#include  "pnl_manager .h" 

#include  "3d.h" 

^include  "3d_tools.h" 

^include  "tools. h"  10 

^include  "graph. h" 

# define  TORAD(x)  (x*M_PI/180.0) 

f*  externals  from  model  */ 

extern  Object_3d  *the_ground,  *planet,  *moon[j; 

extern  float  sphere_radius,  sphere_sides,  njnoons,  orbit_var,  orbitQ ; 

extern  update_model();  20 

/  *  dynamics  parameters  */ 
int  i_time=0; 

float  time_step=1.0,  rotation_scale  =  10.0; 

Point2  sincos[1000]; 

/*  star  background  parameters  *j 

float  n_stars=1000.0,  star_radius=0.05;  30 

Point3  star_list[100000]; 

void  init_stars(); 
float  get_rand(); 

/  *  Graphics  */ 

Graphic  Display,  Theta; 

int  do_axis=FALSE;  40 

int  draw_scene(); 

main()  main 

{ 

init_stars(); 
init_sincos(); 
window_init(); 
set_up_d.isplay  () ; 

while  (TRUE)  {  50 

numerical_calculations(); 
do  window  stuff(); 

} 
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main-numerical_calculations  (planet,  c) 


} 

set  up_display()  Set  up  display 

{ 

/  *  windows  */ 

60 

prefsize(700,  700); 
sprintf(Display. title,  "Planet"); 

Display,  type  =  G_3D; 
init_graph(&Display,  dravv_scene); 

I*  3D  model  */ 

make_model(); 

/*  panels  (needs  model  definition)  */  70 

new_panel("Planet"); 

make_toggle_button("  axis",  &do_axis); 
make_variable("radius",  &sphere_radius,  updatejnodel); 
make_variable("sides",  &sphere_sides,  update_model); 
new.column(); 

make_variable("step",  &time_step,  null_function); 
make_variable("rot",  &rotation_scale,  null_function); 

new_panel("stars");  so 

make_variable("#  stars",  &sn_stars,  init_stars); 
new_column(); 

make_variable("radius",  &star_radius,  null_function); 


} 


float  t^O.O; 

numerical_calculations()  /  *  pseudo  dynamics  */  numerical_CalculationS 

{  _  91 

int  i; 

for  (i=0;  i<n_moons;  i++)  { 

moon[i]— >xform— >position[X]  =  orbit[i]*  sincos[(i+l)*i_time%1000].y; 
moon[i]— >xform—  >position[Z]  =  orbitfij*  sincos[(i+l)*i_time%1000].x; 
moon[ij— >xform— >rotation[Y]  =  rotation_scale*t; 

} 

planet— >xform— >rotation[Y]  —  rotation_scale*t/2.0;  100 

i_time  +~  (int)  time_step; 
i_time  %=  1000; 
t  +=  time  step; 

} 
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numerical_calculations 


init_sincos() 

{ 

int  i=0 ; 
float  x; 

for  (x=0.0;  x<2*M_PI;  x+=  2*M_PI/1000.0)  { 
sincos[i].x  =  sin(x); 
sincos[i++].y  =  cos(x); 

} 

} 


draw_scene() 

{ 

if  (do_axis)  draw_axis(); 

draw_stars(); 

draw_object(the_ground); 

} 

void  init  stars() 

{ 

int  i; 

float  radius,  theta,  phi; 

radius=  FAR/3.0; 

for  (i=0;  i<n_stars;  i++)  { 

theta  =  M_PI*get_rand(); 
phi  =  M_PI*get_rand(); 

star_list[i].x  =  radius*sin(theta)*cos(phi); 

star_list[i].y  =  radius*sin(phi); 

star  list[i].z  =  radius*cos(theta)*cos(phi); 

} 

} 

float  get  rand() 

{ 

return(  1.0  -  2.0*(rand()  %  1000)/1000.0  ); 

} 


draw_stars() 

{ 

int  i; 


} 


RGBcolor(200,  220,  250); 
for  (i=0;  i<n_stars;  i++)  { 

star(star  list[i],  star_radius); 

} 


draw_stars  (planet,  c) 

init_sincos 

110 


draw_scene 

120 


130 


140 


draw_stars 

150 
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(Makefile) 


# 

ff  Makefile  for  GSMS  "elephant"  application  5/30/91  A.T. 

# 

ELEPHANT. 0  —  elephant. o  model.o 
IRIS  =  IRIS.4D 

GSMS_DIR  =  /everest/users/tonyt  10 

INCLUDE_DIR  :=  $(GSMSJDIR)/include 
LIB_DIR  =  $(GSMS_DIR) /lib 

INCLUDE_DIRS=  -I$(INCLUDE_DIR)  -I/usr/local/include 
LIB_DIRS=  — LS(LIBJDIR)  -L/usr/local/lib 

GSMS_LIB  =  — lgraph  — lpnl_mngr  —llinkjist  — lpanel 
LIBES~  =  S(GSMS_LIB)  -lgl  -1m 

20 

CFLAGS  =  -DS(IRIS)  $(INCLUDE_DIRS)  $(LIB_DIRS) 
elephant:  S(ELEPHANT.O) 

$(CC)  S(CFLAGS)  S(ELEPHANT.O)  -o  elephant  S(LIBES) 
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make  jno  del  (mo  del. c) 


^include  <gl.h> 

^include  <math.h> 

^include  "display .h" 

^include  "light. h" 

^include  "3d_tools.h" 

^include  "elephant  .h" 

I*  Note:  This  code  is  generalized  to  generate  N  legged  creatures  with  each  leg 

described  by  N_JOINTS  number  of  rigid  links.  To  retrieve  the  elephant  10 

trunk  simply  define  N  LEGS  as  1. 

7 

float  *jx[N_LEGS] [N_J OINTS] ,  *jy[N_LEGS][N_JOINTS],  *jz[NLEGS][N_JOINTS]; 
float  length[N_JOINTS]; 

float  radius=0.3,  height=1.2; 
float  n_sides  =  30; 

Object_3d  *the_ground,  *Head,  *current_0;  20 

Cylinder  cyl; 

Sphere  head; 

makemodei()  make  model 

{ 

int  ij; 
double  x; 

make_sphere(&;head,  3.3*radius,  40,  GREY_MAT,  GREY_MAT); 

make  left,_cylinder(&cyl,  0.5,  height,  (int)  n_sides,  30 

GREY_MAT,  GREY_MAT,  GREY_MAT,  GREY_MAT,  >z>); 

the_ground  =  new_object(); 

Head  =  spawn_next(SPHERE,  (char  *)  &head,  the_ground, 

new_transform( 

1.0,  1.8,  1.2, 

0.0,  0.0,  0.0, 

0.0,  0.0,  0.0  ) 

);  40 


for  (j=0;  j<N_LEGS;  j++)  { 
i— 0; 

x  =  2.0*3. 1415*j/((float)  N_LEGS); 
spawn_sub(CYLINDER,  (char  *)  &xyl,  Head, 

new_transform( 

0.95,  0.95,  0.85, 
sin(x),  0.0,  cos(x), 

10.0,  360.0*j/((float)  N  LEGS),  0.0) 

);  . 

jxjj]  [i]  =  &;current_0— >xform— >rotation[X]; 
jy[j][i]  =  &current_0— >xform— >rotation[Y]; 

J z  D  ]  [i]  —  &current_0— >xform— >rotation[Z]; 
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makemodel(model.c) 


for  (i=l;  i<N_JOINTS;  i++)  { 

spawn_sub(CYLINDER,  (char  *)  &cyl,  current_0, 
new_transform( 

0.95,  0.95,  0.85, 

0.0,  0.0,  1.1,  so 

10.0,  0.0,  0.0  ) 

); 

jx[j][i]  —  &current_0— >xform— >rotation[X]; 
jy[j][i]  =  &current_0— >xform— >rotation[Y]; 
jz[j][i]  =  &current_0— >xform— >rotation[Z]; 

} 

} 

} 

70 
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set_up_display  (elephant,  c) 


^include  <stdio.h> 

^include  <math.h> 

^include  <gl.h> 

^include  "math.h" 

^include  "display. h" 

^include  "light. h" 

^include  "3d_tools.h" 

^include  "tools. h" 

^include  "graph. h"  10 

^include  "elephant  .h" 

j*  variables  from  model  */ 

extern  Object_3d  *the_ground,  *Head; 
extern  float  radius,  height,  n_sides; 

extern  float  *jx[N_LEGS][N JOINTS],  *jy[N_LEGS][N_JOINTS],  *jz[N_LEGS][N_JOINTS]; 
float  length[20]; 

/*  booleans  */  20 

int  x_rot=FALSE,  y_rot=FALSE; 

/*  misc  */ 
int  mode=SIN; 

float  step=1.0,  freq  =  0.1,  star_diameter=0.2; 

Point3  target; 

/*  procedures  */  30 

int  draw_scene(),  reset_simulation(); 

/*  Graphics  */ 

Graphic  Display; 


main() 

{ 

window_init(); 

set_up_diisplay(); 

wliile(TRUE)  { 

numerical_calculations() ; 
do_window_stuff() ; 

} 

} 


set_up  display() 

{ 

int  ij; 
cliar  *s_ptr; 


main 

40 


set_up_display 

50 
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set  up  display— numericalcalculations(elephant.c) 


prefsize(800,  650); 
sprintf(Display. title,  "Elephant"); 
Display. type  =  G_3D; 
initjp:apli(kDisplay,  draw_scene); 


target. x  —  5.0; 
target. y  =  0.0; 
target. z  =■  0.0; 

make_model(); 

new_panel("  Control"); 

make_slider("step",  1.0,  10.0,  kstep); 
make_slider("freq",  0.01,  0.09,  kfreq); 
new_column(); 

make_toggle_button("  y_rot",  ky_rot); 
make_toggle_button("  x_rot",  kx_rot); 
rnake_button("  reset",  reset_simulation); 

new_panel(  "Transform"); 

make_slider("head  y",  —360.0,  360.0,  kHead— >xform—  >rotation[Yj); 
for  (i=0;  i<N_JOINTS;  i++)  { 

s_ptr  =  (char  *)  malloc(30); 
sprintf(s_ptr,  "joint  i+1); 

make  slider(s  ptr,  —30.0,  50.0,  jx[0] [i]); 

} 

new_panel("Target"); 

make_variable("length",  kstar_diameter,  null_function); 
make_slider("x",  —10.0,  10.0,  ktarget.x); 
make_slider("y",  —10.0,  10.0,  ktarget.y); 
make_slider("z",  —10.0,  10.0,  ktarget.z); 

} 

double  t; 


60 
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SO 


numerical_calculations()  / *  position  control?  HA!  ( for  exhibition  only)  */D.UITierical_CcLlculationS 
{  91 

int  ij; 

for  (j=0;  j<N_LEGS;  j++) 
for  (i=0;  i<N_JOINTS;  i++)  { 

switch(mode)  { 

case  RANDOM: 

if  (x_rot)  *jx[j][i]  — =  step*(  (rand()%  1000)/1000.0  —  0.5);  100 

if  (y_rot)  *jy[j][i]  — =  step*(  (rand()%  1000)/1000.0  -  0.5); 

break; 


case  SIN: 

if  (x_rot)  *jx[j][i]  —  =  step*sin(freq*t); 
if  (y_rot)  *jy[j][i]  — =  step*cos(freq*t); 
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numericalj:alculations-draw  tar  get  (elephant,  c) 


t  +—  0.1; 
break; 

} 

} 

} 

reset_simulation() 

{ 

int  1  j ; 

for  (j=0;  j<N_LEGS;  j++)  { 
i— 0; 

*jy[j][i]  =  j*360.0/((float)  N_LEGS); 
for  (1=1;  i<N  JOINTS;  i++)  { 
*jx[j][i]  =  10.0; 

*jy[i][i]  =  0.0; 

\ 

J 

} 

} 

draw_scene() 

{ 

draw_axis(); 

draw_object(the_ground); 

draw_target(); 

} 

draw  target() 

{ 

RGBcolor(100,  100,  220); 
star(target,  star  diameter); 

} 


110 


reset_simulation 
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draw_scene 


130 


draw_target 
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